home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 3362 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.4 KB  |  39 lines
  1. Newsgroups: comp.sys.amiga.applications,comp.sys.amiga.programmer
  2. Path: bath.ac.uk!bspwrb
  3. From: bspwrb@bath.ac.uk (W R BENNETT)
  4. Subject: Re: Wanted: Small and fast FindTool 
  5. Organization: School of Biological Sciences, University of Bath, UK
  6. Message-ID: <DMIp0L.86o.B.mary@bath.ac.uk>
  7. References: <68771426@0humpty.tomate.tng.oche.de>
  8. Date: Fri, 9 Feb 1996 16:41:10 GMT
  9.  
  10. In the referenced article, humpty@TOMATE.TNG.OCHE.DE (Andreas Mixich) writes:
  11. >
  12. >    Hi,
  13. >
  14. >I am using Find (the one which needs "FindDB:") but the problem with it is,
  15. >that after having scaned my hd I have gotten a datafile of more than 700
  16. >kilo. Additionally I packed it. Now Find needs more then 1 meg free chunk
  17. >to use the datafile. Unpacking it before is no win either. Is there any
  18. >similare tool, that
  19. >
  20. >a) does not need the assign
  21. >b) does not need to read in the whole database at once ?
  22. >c) is CLI based
  23. >
  24. >I said, even using an unpacked datafile seems to need that large free
  25. >memory chunk.
  26. >
  27. There's a program in a package called QuickTools which does the same 
  28. job.  It does need an assign, but it builds a separate file for each 
  29. partition, so this will probably reduce the size of your datafiles to a 
  30. manageable level.  The search tool is CLI-based, fast and searches all 
  31. the datafiles sequentially.  If QuickTools isn't on Aminet, it may have 
  32. come from a Fish disk - I can search and find out if required.
  33.  
  34. Cheers,
  35.  
  36. Bill Bennett
  37. W.R.BENNETT@bath.ac.uk
  38.  
  39.